Black Crawling Systems Archive Release 1.0

home *** CD-ROM | disk | FTP | other *** search

/ Black Crawling Systems Archive Release 1.0 / Black Crawling Systems Archive Release 1.0 (L0pht Heavy Industries, Inc.)(1997).ISO / blackcrwl / releases / cops-rl.txt < prev next >

Wrap

Text File | 1992-01-10 | 24KB | 477 lines

* R e n e g a d e L e g i o n * RL C.O.P.S. File by Brian Oblivion Technical Report #7 May 1991 The Night Elite BBS (RL HeadQuarters) : (617) oOo-oOOo The Electric Eye ][ (RL Support Site) : (313) 776-8928 Mind Of 'a Lunatic (RL Support Site) : (714) 693-0957 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Well, due to the increasing popularity of this package of utilities, I feel that everyone should be aware of it, watch for it, and avoid it. Looking at the file one will say, by Jove! how easy it would be to modify this program to report to me all the flaws of a system. And so it should be done. At any rate, absorb the information. The package, which will be henceforth be referred to as COPS (Computer Oracle and Password System), can be broken down into three key parts. The first is the actual set of programs that attempt to automate security checks that are often performed manually (or perhaps with self written short shell scripts or programs) by a systems administrator. The second part is the documentation, which details how to set up, operate, and to interpret any results given by the programs. Finally, COPS is an evolving beast. It includes a list of possible extensions that might appear in future releases, as well as pointers to other works in UNIX security that could not be included at this time, due to space or other restrictions. This document contains six sections: 1) What is COPS? 2) What COPS is _not_ 3) How to Configure COPS 4) Running COPS for the 1st Time 5) Continued Use and Installing COPS 6) Disclaimer and End Notes 1) What is COPS? ----------------- COPS is a collection of about a dozen (actually, a few more, but a dozen is such a good sounding number) programs that each attempt to tackle a different problem area of UNIX security. Here is what it currently checks: o file, directory, and device permissions/modes. o poor passwords. o content, format, and security of password and group files. o the programs and files run in /etc/rc* and cron(tab) files. o finds SUID files, and checks for their writeability and if they are shell scripts. o runs a crc check against important binaries or key files, and reports any changes therein. o writability of users home directories and startup files (.profile, .cshrc, etc.) o anonymous ftp setup. o unrestricted tftp, decode alias in sendmail, SUID uudecode problems. o miscellaneous root checks -- current directory in the search path, a "+" in /etc/host.equiv, unrestricted NFS mounts, ensures root is in /etc/ftpusers, etc. o includes the Kuang expert system, that takes a set of rules and tries to determine if your system can be compromised (for a more complete list of all of the checks, look at the file "release.notes" or "cops.report"; for more on Kuang, look at at "kuang.man".) All of the programs merely warn the user of a potential problem -- COPS DOES NOT ATTEMPT TO CORRECT OR EXPLOIT ANY OF THE POTENTIAL PROBLEMS IT FINDS! COPS either mails or creates a file (user selectable) of any of the problems it finds while running on your system. And because COPS does not correct potential hazards it finds, it does _not_ have to be run by a privileged account (i.e. root or whomever.) The only security check that should be run by root to get maximum results is the SUID checker; although it can be run as an unprivileged user, to find all the SUID files in a system, it should be run as root (in addition, if key binaries are not world readable, only executable, the CRC checking program ("crc.chk") needs to be run as a privileged user to read the file in question to get the result.) In addition, COPS cannot used to probe a host remotely; all the tests and checks made require a shell that is on the site being tested. The programs are mostly written in Bourne shell (using awk, sed, grep, etc. as well) for (hopefully) maximum portability. A few are written in C for speed (most notably the Kuang expert system and for implementing fast user home directory searching), but the entire system should run on most BSD and System V machines with a minimum of tweaking. 2) What COPS is _not_ ---------------------- COPS merely provides a method of checking for common procedural errors. It is not meant to be used as a replacement for common sense or user/ operator/administrative alertness! Think of it as an aid, a first line of defense -- not as an impenetrable shield against security woes. An experienced wrong-doer could easily circumnavigate _any_ protection that COPS can give. However, COPS _can_ aid a system in protecting its users from (their own?) ignorance, carelessness, and the occasional malcontent user. Once again, COPS does not correct any errors found. There are several reasons for this; first and foremost, computer security is a slippery beast. What is a major breach in security at one site may be a standard policy of openness at another site. Additionally, in order to correct all problems it finds, it would have to be run as a privileged user; and I'm not going to go into the myriad problems of running SUID shell scripts (See the bibliography at the end of the technical report "cops.report" for pointer to a good paper on this subject by Matt Bishop.) At this time, COPS does not attempt to detect bugs or features (such as the infamous ftpd, fingerd, etc) that may cause security problems. Although this may change in future versions, the current line of reasoning to avoid general publication of programs such as these is that all the problems that COPS detects can be repaired on any system it runs on. However, many bugs can be readily repaired only be having source code (and possibly a good vendor to repair it), and many sites would have serious troubles if they suddenly discovered unrepairable problems that could compromise their livelihood. It is possible that a more controlled release may come out in the future to address such problems (but don't mail to me about getting them -- unless you want to help write them! :-)) 3) How to Configure COPS ------------------------- System V users, other Non-BSD systems, or sites with commands in strange places -- you may have to run a shell script called "reconfig" to change the pathnames of the executable programs called when using COPS. If your system does not use the paths listed in the shell scripts, try running "reconfig". This will reconfigure the pathnames used by COPS to your system; COPS should run fine then, if it can find all of the commands (reconfig should tell you if it cannot.) If trouble persists, you will have to change the paths to your executable files (awk, sed, etc) by hand. A drag, I know. This all may change without notice, anyway :-) With all the varieties of unix, there are a few types that may need extra help to run the system. I've got README files for Apollo and Xenix in the distribution -- see the files "README.apollo", and "README.xenix", respectively -- if you have any troubles, drop me a line, and I'll see what I can do about working out a patch with you. Some problems might arise with some SYSV machines (heck, to any machine :-)), due to weird files and names for stuff. What can I say? Portability is a problem. You can comment out line 39 and 38 in "misc.chk", if you use /etc/servers instead of /etc/inetd.conf. 4) Running COPS for the 1st Time --------------------------------- Since most of COPS was written and tested mostly on just a few machines (at least compared to the total number out there!), you may have significant differences that were not anticipated -- unfortunately, or fortunately, UNIX is not quite standardized yet. However, I haven't run into a UNIX yet that I haven't been able to get it running on, with just a small amount of change, so feel free to mail to me for help. COPS is run by simply typing "cops". "cops" is a Bourne shell script that runs each of the programs, accumulates the output, and then either mails or stores any results in a file. "suid.chk" (and possibly "crc.chk") is the only package that is meant to be run separately, simply because it can take a long time to run, and possibly because it needs a privileged account to run it; look at "suid.man" for more information. By all means, however, do not ignore the SUID checker! Run it at least once a week, if possible, more (daily?); intruders into a system often leave SUID files to gain privileges later. "crc.chk" should also be run; it can either be run as a standalone program (preferred), or as part of the COPS package; read the file "CRC.README", and the man page for more information. To run COPS for the first time, I suggest doing the following: -- Look at the disclaimer, file "disclaimer". Don't sue me. Actually, this holds for all the times you use COPS (1/4 :-)) -- Type "make" and "make docs" to create the formatted manual pages, to compile the C programs, and to make the shell programs executable. A couple of potential (hopefully minor problems) might occur, probably only for SysV based machines; one, if you don't have the "-ms" package for nroff (i.e. you, get an error message after typing "make" about it), just remove the "-ms" flag; e.g., change line 7 of the "docs/makefile" file, from: ROFFLAGS = -ms to ROFFLAGS = The second potential problem might be with the password checking program; if it fails to compile, try uncommenting out line 20 in "makefile" -- e.g., enable the "BRAINDEADFLAGS = -lcrypt" flag. If this doesn't work... well, you can either work it out, or e-mail me. -- Read the technical report to understand what COPS is doing and what is going on -- "cops.report". This gives a look at the philosophies, design notes, and finally a general outlay of the COPS system and UNIX security. This can be forsaken, for those who just want to get to the results/see some action (people like me.) -- Next, change lines 51 and 52 in the "cops" shell file; this is what they were: SECURE=/usr/foo/bar SECURE_USERS="foo@bar.edu" SECURE should be the same directory as the directory that contains the cops programs, and SECURE_USERS should be your own login id, or to whomever you designate as the recipient of the output (your enemy?) -- Set "MMAIL=NO" in the "cops" shell file (line 25). This will prevent a large mail file from choking the mailer. All of the output will be put into a file called "year_month_day" (obviously, that's like: "1991_Dec_31", not actually the words, "year_month_day" :-)), and should be automatically placed by COPS in a directory that has the same name as the host it was run on (e.g., your own hostname.) -- Look at the directory and file configuration file, "is_able.lst" This contains critical files that COPS checks for group and world writability and readability. Add or delete whatever files/directories you wish; if a file doesn't exist, COPS will effectively ignore it. (If you don't know or are uncertain what files/directories are important, what is given there is a good set to start with on most systems.) -- If you allow anonymous ftp access to your system, add a "-a" flag to "ftp.chk" on line 104 of "cops". Right now, it is set up so that key files and directories are expected to be owned by root; however, it has provisions for two owners, $primary and $secondary -- some may wish to change the second to "ftp", or some other user. Read the man page for ftp.chk, or look at "ftp.chk" for further notes. -- You may wish to comment out the password checker (line 109 in the "cops" shell file). Although this is not necessary, it will speed up the package if you wish for immediate gratification. If you are using yellow pages/NIS, read "README.yp" for tips on how to check passwords there. -- Uncomment out the crc checker, "crc.chk" (line 123), if you desire to run it as part of the normal COPS run. You should be ready to roll. COPS is run by simply typing "cops" (you may wish to put in the background....) If you followed my advice and set "MAIL=NO" in the "cops" shell file, after COPS is finished, there will be a report file created ("year_month_day") that lists the time and machine it was created on. Otherwise, COPS mails the report to the user listed on the line 'SECURE_USERS="foo@bar.edu"'. There is a file "warnings", which contains most of the warning messages COPS uses, as well as a brief explanation of how the message might pertain to your system and finally a suggestion as how to "fix" any problem. NOTE: Change the shell script "cops" to reflect who you want the output sent to and where the location of the program is BEFORE running the program. 5) Continued Use and Installing COPS ------------------------------------- Once you are satisfied that COPS indeed does something useful (hopefully this will occur :-)), a good way to use it is to run it on at least a semi-regular basis. Even if it doesn't find any problems immediately, the types of problems and holes it can detect are of the sort that can pop up at any given time. One way of running COPS might be to run it as an "at" job or by cron. I highly advise that whatever directory COPS is placed in is to be readable, writable, and executable only by the owner (typing "chmod 700 /usr/foo/bar" or whatever the name is will do this) of the directory. This is to prevent prying eyes from seeing any security problems your site may have. Even if you don't think of them as important, someone else might come around and change your mind. Since COPS is fairly configurable, an intruder could easily change the paths and files that COPS checks for, hence making it fairly worthless. Again, this comes back to the point that COPS is only a tool -- don't put down your defensive shields merely because COPS says "all clear". If this sounds paranoid, it is! Security people are traditionally paranoid, for a reason.... In any case, it is probably not a good idea to advertise any (even) potential weaknesses. Typing "make install" will create (if necessary) a subdirectory with the name you put in $INSTALL_DIR (found on line 7 of "makefile"); if you run a network with multiple architectures, you can have several executable versions of COPS in the same NFS mounted directory structure. You can run COPS with "cops archtype", and it will cd into the archtype directory, use the binaries in that directory (placed there by a "make install"), and put any results in a subdirectory of the archtype directory with the appropriate host name. For example, assume you have the following setup: machine architecture hostname If run COPS with: ===================== ======== ================== cray ribcage cops vax bar cops vax vax foo cops vax sun earth cops sun sun mars cops sun sun venus cops sun mips hades cops If $SECURE (the secure directory variable in the "cops" shell script) was set to "/usr/secure", the resulting directory/reporting structure would be: /usr/secure/cops/ribcage /usr/secure/cops/vax/bar /usr/secure/cops/vax/foo /usr/secure/cops/sun/earth /usr/secure/cops/sun/mars /usr/secure/cops/sun/venus /usr/secure/cops/hades Sometimes you will get the same report over and over again, everytime you run COPS; for instance, with Ultrix 3.x, /dev/kmem is world readable -- this is a security hole, but many utilities in Ultrix need this to function. If you wish to only see reports that are _different_ than the old reports, you first need to have an older report saved in a file (in $SECURE/hostname, or wherever you usually save the reports); you can then set "MMAIL=YES" _and_ "ONLY_DIFF=YES" (lines 25 & 30, respectively) in "cops"; everytime COPS is run after that, it will compare the report it generated for the current check with the old report; if it detects any differences, it will mail you a report. If not, it simply discards it. This can be a real boon for a site with a lot of machines running COPS every night... There are a couple of further options you may wish to explore. First of all, since so many breakins are because of poor passwords selection by users, it would be a wise idea to add options to your password checking program (line 109 in "cops"). You may wish to try some words from a dictionary; you may use either your system dictionary (usually found in /usr/dict/words), or you may use the same dictionary that the internet worm found so lucrative when hitting all those thousands of hosts; that dictionary is in the file "pass.words" (example; the way to include the worm dictionary is: "pass.chk -w pass.words"). Also, try some of the options in the password program, such as "-b", "-g", "-s", and "-c", which add checks for backward, gecos, single letter & number, and upper and lower case guesses, respectively. Just as a note, each option will increase the time needed to crack the passwords, of course; experiment! See what is reasonable for your hardware and resource capabilities. By using the "pass_diff.chk" program, you only check accounts that have _changed_ their password since the last time you've checked -- this can save enormous amounts of times with large systems; you can check your users thoroughly once, then only check them as they change their passwords again. Be careful, though, if you use this, and then later expand your checks and/or your dictionary used to search for passwords, the earlier accounts that were already checked with an inferior method will not be checked again until they change their password. See the file "passwords" in the "extensions" directory for a replacement "passwd" program, that can disallow poor passwords to begin with. The file "is_able.lst" contains a list of files that are to be checked for world readability and/or writability; look at the file; add or delete any files you feel are important to your system. After running COPS, if any warnings are given that compromise any individual users accounts (such as world writable .profiles, home directories, guessed passwords, etc.), and the warnings are not corrected immediately (or you are not sure whether or not it is worth hassling the user to change it), try this: Edit the file "init_kuang", and add the compromised user(s) uids and groups in their respective target lines (below lines 20 and 27, respectively), and run kuang again to see if the users can compromise the entire system. You may change your mind about not thinking they are a problem! In addition, kuang does not have to have "root" as a target (the last line). Try putting in system administrators or other powerful figures to see if they are in danger as well. If you have "perl" installed on your system, try the perl version of kuang -- "kuang.pl" (you'll have to unpack the shar file this is inside -- "kuang.pl.shar", and you may have to edit the first line of the file "kuang.pl", to reflect where the location that perl is on your system.) 6) Disclaimer and End Notes ---------------------------- COPS is meant to be a tool to aid in the tightening of security, not as a weapon to be used by an enemy to find security flaws in a system. It may be argued that allowing anyone to have access to such a tool may be dangerous. But hopefully the overall benefit for systems that use this package will outweigh any negative impact. To me it is akin to a law enforcement problem -- that although telling the public how to break into a house may foster a slight rise in break-in attempts, the overall rise in public awareness on how to defend themselves would actually result in a drop in break-ins. The crackers with black hats already know how to crush system defenses and have similar tools, I'm sure. It's time we fought back. COPS is not the final answer to anyone's security woes. You can use the system as long as you realize that COPS has no warranty, implied or otherwise, and that any problems that you may have with it are not my or any of the other authors' fault. I will certainly attempt to help you solve them, if I am able. If you have ideas for additional programs, or a better implementation of any of the programs here, I would be very interested in seeing them. COPS was the work of a LOT of people, both in writing code and in the testing phase (thanks beta testers!). For a complete list of contributors, look at the file "XTRA_CREDIT". So good luck, and I hope you find COPS useful as we plunge into UNIX of the 1990's. dan farmer January 31, 1989 (Now January 31, 1990) # include "./disclaimer" Just for snix, here are some of the machine/OS's I know this sucker works on; far and away the most common problem was getting that stupid password cracking program to compile, followed by systems without the -ms package to nroff. Some minor problems with config files -- I *think* these are all ok: DECstation 2100, 3100, 5000, Ultrix 2.x, 3.x, 4.x (It should, I'm sitting in front of one now. Ultrix is braindead) Sun 3's, 4's (incl. Solbourne) -- 3.x, 4.x Gould 9080 Powernode, hacked up Gould OS (whatever it is) sequent S-87 symmetry, dynix V3.0.12 (both att & bsd universes; att required "BRAINDEADFLAGS = -lcrypt" to be uncommented. eta-10P, Sys V R3 based Convex boxes, all types, most OS's (up to 9.x, the most recent) Apollo dn3000 & dsp90, Domain SR 9.7 Vax 11/780, 4.3 BSD (Mt. Xinu, tahoe and stock) Vaxstation, MicroVax, Vax 6320 & 8800, Ultrix 2.0, 3.x HP900/370, HP-UX 6.5 Cray 2 & Y-MP, UNICOS 5.0, 6.0 Amdahl 5880, UTS 580-1.2.3 SGI 2500's, IRIX GL 3.6 SGI 4D's, IRIX System V Release 3.X '286 & '386 Boxes, running Xenix (README.xenix) Apple Mac IIci, running AUX 2.x. The "test -z" seemed broken on this, but I only had a brief chance to test it out, but kuang didn't like it as a result. I'll get a working version soon; everything seemed ok (change the /etc/servers line in "misc.chk".) NeXT, 1.x (password stuff is different on this machine, tho; cracking is strange. Diffs?) Multimax 320, 12 Processors, 64Mb Memory, Encore Mach Version B1.0c (Beta) (no crypt(3) on this machine. Sigh.) IBM rs6000, AIX 3.1 (BRAINDEAD -- boo. hiss.) COPS will *NOT* work well on this piece of trash -- the shell utilities are garbage; however, you can still get *some* useful info. I'm not going to rewrite everything because big-blue won't write an awk that works: